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Abstract 

For over a decade, researchers in formal methods tried 
to create formalisms that permit natural specification 
of systems and allow mathematical reasoning about 
their correctness. The availability of fully-automated 
reasoning tools enables more non- specialists to use for- 
mal methods effectively — their responsibility reduces 
to just specifying the model and expressing the desired 
properties. Thus, it is essential that these properties 
be represented in a language that is easy to use and 
sufficiently expressive. 

Linear-time temporal logic [21] is a formalism that 
has been extensively used by researchers for specify- 
ing properties of systems. When such properties are 
closed under stuttering, i.e. their interpretation is 
not modified by transitions that leave the system in 
the same state, verification tools can utilize a partial- 
order reduction technique [16] to reduce the size of the 
model and thus analyze larger systems. If LTL formu- 
las do not contain the "next" operator, the formulas 
are closed under stuttering, but the resulting language 
is not expressive enough to capture many important 
properties, e.g., properties involving events. Deter- 
mining if an arbitrary LTL formula is closed under 
stuttering is hard — it has been proven to be PSPACE- 
complete [25]. 

In this paper we relax the restriction on LTL that 
guarantees closure under stuttering, introduce the no- 
tion of edges in the context of LTL, and provide theo- 
rems that enable syntactic reasoning about closure un- 
der stuttering of LTL formulas. 



1 Introduction 

Formal specification of systems has been an active 
area of research for several decades. From finite-state 
machines to process algebras to logics, researchers 
try to create formalisms that would permit natural 



specification of systems and allow mathematical rea- 
soning about their correctness. However, most of 
these formalisms have not been adopted widely outside 
academia — their cost-saving benefits were doubtful, 
they lacked tool support, and were perceived difficult 
to apply [27]. 

Recently, the tools for proving properties of finite- 
state models are becoming increasingly available and 
are often used for analyzing requirements, e.g. [2, 3, 
10, 4]. These tools typically require the users to spec- 
ify properties using temporal logics and to describe 
models of systems using some finite-state transition 
representation. The tools are based on a variety of 
verification techniques. For example, SPIN [16] and 
SMV [22] are based on state-space exploration, also 
called model- checking, Concurrency Workbench [6] on 
bisimulation, and COSPAN [11] on language contain- 
ment. Most finite-state verification techniques can be 
fully automated, and the responsibility of the user re- 
duces to just specifying the model and expressing the 
desired properties. In this context, it is important 
that properties can be represented in a language that 
is easy to use and sufficiently expressive, to enable 
even fairly novice users to use it effectively. 

Linear-time logic (LTL) [21] is a temporal logic that 
has been extensively used by researchers for specify- 
ing properties of systems. A highly desirable property 
of LTL formulas is that they are closed under stut- 
tering [1]. In particular, the mechanical analysis of 
such formulas, such as by the model-checker SPIN [16], 
can utilize powerful partial-order reduction algorithms 
that can dramatically reduce the state-space of the 
model. Unfortunately, closure under stuttering can 
be guaranteed only for a subset of LTL [18], and this 
subset is not expressive enough to represent even fairly 
simple properties, such as: 

The magnet of the crane may be deactivated 
only when the magnet is above the feed belt. 

Users of LTL typically try to remedy this problem by 



introducing extra variables inside the model — a tech- 
nique which tends to clutter the model, enlarge the 
state space, and introduce errors. 

Determining whether an LTL formula is closed un- 
der stuttering is hard: the problem has been shown to 
be PSPACE-complete [25]. Even though a complete 
solution is impractical, we have been able to catego- 
rize a subset that is useful in practice. In particular, a 
computationally feasible algorithm which can identify 
a subclass of closed under stuttering formulas has been 
proposed in [15] but not yet implemented in SPIN. 
The algorithm is fairly sophisticated and cannot be 
applied by hand. Moreover, it is not clear how often 
the subclass of formulas identified by the algorithm is 
encountered in practice. 

In this paper we relax the restriction on LTL that 
guarantees closure under stuttering, introduce the no- 
tion of edges in the context of LTL, and provide the- 
orems that enable syntactic reasoning about closure 
under stuttering of LTL formulas. The rest of the 
paper is organized as follows: Section 2 provides some 
background on LTL and the notation used throughout 
the paper. Section 3 discusses closure under stuttering 
and introduces edges. Section 4 gives some important 
properties of edges and closure under stuttering. Sec- 
tion 5 describes an application of this work to property 
patterns identified by Dwyer and his colleagues in [8]. 
We discuss some alternative approaches in Section 6 
and conclude the paper in Section 7. 



2 Background 

We begin by briefly introducing our notation which 
we have adopted from [12]. A sequence (or string) 
is a succession of elements joined by semicolons. For 
example, we write the sequence composed of the first 
five natural numbers, in order, as 0; 1; 2; 3; 4 or, more 
compactly, as 0; ..5 (note the left-closed, right-open in- 
terval) . We can obtain an item of the sequence by sub- 
scripting: (0; 2; 4; 5)2 = 4. When the subscript is a se- 
quence, we obtain a subsequence: (0; 3; 1; 5; 8; 2)i:2:3 = 
(0;3;l;5;8;2)i,.4 = 3;l;5. 

A state is modeled by a function that maps vari- 
ables to their values, so the value of variable a in state 
So is so{a). We denote the set of all infinite sequences 
of states as St°°, and the set of natural numbers as N. 

Boolean expressions are connected by -i(not), A 
(and), V (or), =^ (implies), <^ (is implied by), and = 
(if and only if). To reduce the clutter of parenthesis, 
we denote the main connective in a formula by a bigger 
and bolder symbol, e.g. ^. We consider the connec- 
tives to have decreasing precedence as follows: —, ->, A, 



V, ^; the connectives ^, =^, and <= have the lowest 
precedence. For example, the formula aAbVb^a =^ b 
should be parsed as: ((a A 6) V 6) ^ (a =^ 6). 

Linear time temporal logic (LTL) is a language for 
describing and reasoning about sequences of states. 
These sequences can be interpreted in a variety of 
ways: the state of the world as it evolves over time, 
the state of a program as it is executing, and so forth. 
Informally, LTL is comprised of propositional formulas 
and temporal connectives □ (always), O (eventually), 
o (next), and U (until). The first three operators are 
unary, while the last one is binary. Using these opera- 
tors, one can express properties about the evolution of 
a system. For example, a formula pV oq indicates that 
cither p holds in the starting state of the system, or 
q holds in the following state. A formula D[p ^ <}q) 
indicates that each occurrence of p is followed, at some 
point, by an occurrence of q. We now define the formal 
semantics of an LTL formula, based on its syntactic 
structure. Let A and B be LTL formulas, let a be a 
variable name, and let s be a sequence of states, i.e. 
s G St°°. We denote an interpretation of formula F 
in state sequence s as sl-F], and define it as follows: 
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sl^Aj 


= MA] 


slAABj 


= slAJAslBj 


sfoA] 


= Sl,.oolAj 


spA] 


= V*eN-s,,.ooIAl 
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slAUBj 


= 3ieN-(s,,.oolSlA 
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For example, s|Oj4] means that a formula A must hold 
at some point i in the sequence s. We do not describe 
other boolean operators as they can be expressed in 
terms of negation and conjunction. 

We say that an LTL formula F is closed under stut- 
tering when its interpretation remains the same under 
state sequences that difi^er only by repeated states. We 
denote a closed under stuttering formula as -^F^, 
and formally define it as follows: 

Definition 1 <i^>= 

Vs e St°° • Vi G N • slFj = (so,.i; s,; s,,..^)lF] 

In other words, given any state sequence s, we can 
repeat any of its states without changing the interpre- 
tation of F. Note that so;..^; Si; Si-,, 00 is a sequence of 
states that differ from s only by the repeated state s^. 
It is easy to see that any LTL formula that does not 
contain the "o" operator is closed under stuttering. 



For example, Da is closed under stuttering because no 
matter how much we repeat states, we cannot change 
the value of a. On the other hand, the formula oa 
is not closed under stuttering. We can see that by 
considering the state sequence s in which sq (a) is true 
and si(o) is false. Then oa is false when we evaluate 
it in s, and true when we evaluate it in so;s. 



stuttering does not change its interpretation from the 
current to the next state. Therefore, we can define F 
as -1 A A oA. Note that F is guaranteed to be false only 
when the sequence starts with a repeated state. 

We now claim that the formula developed above is 
closed under stuttering: 

Theorem 1 



3 Closure Under Stuttering and Edges 

Our aim is to capture a large set of formulas that 
use the "o" operator but are still closed under stutter- 
ing. We begin by developing the intuition behind the 
main theorem that enables us to generate this class of 
formulas. Let B be an LTL formula that is closed un- 
der stuttering. Consider the formula oB: it may not 
be closed under stuttering; furthermore, we can not 
correct this by simply quantifying oB with '□' or 'O'. 
To understand how stuttering can modify the inter- 
pretation of oB, we illustrate two different stuttering 
scenarios in Figure 1, where s is a sequence of states, 
and s' and s" are derived from s by stuttering the fifth 
and the first states respectively. Note that the type of 
stuttering exemplified in s', that is, repeating any part 
of the sequence with the exception of the first state, 
causes no harm because B itself is closed under stut- 
tering. However, stuttering the first state, as shown in 
s", may cause problems, because oB is evaluated on a 
state sequence that includes the new state. 
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Figure f : Effects of stuttering on formula oB. 

To circumvent this problem, we conjoin oB with 
another formula, F, and quantify the resulting expres- 
sion with 'O': 0(F A oB). We need the quantification 
to "follow" the state si, as sq can be stuttered any 
number of times, while the conjunct F is needed to 
ignore the leading sequence of repeated states so-^ A 
possible way to determine when a state is repeated is 
to check that an LTL formula A that is closed under 



<A> A <B> ^> <0(-.A AoAA oB)> 

Proof Sketch: Let s,s' G St°°, such that s' is the 
same as s except that the first state of s' is not stut- 
tered. In other words, we can repeat the first state of 
s' a number of times and obtain s. We can rewrite 
the formula 0{^A A oyl A oB) as 0{->A A oG), where 
G = AaB. If we let F = 0{^A A oG), we can see 
that s|F] = s'|F]. So, the interpretation of F is not 
affected by stuttering except perhaps when we stutter 
the first state sq- We have argued in the discussion 
leading to the theorem that this is the case provided 
that A and G are closed under stuttering, which is 
true here. Thus, we only need to worry about state 
sequences s which have the first state stuttered. How- 
ever, in such cases the expression -^A A oA becomes 
false because A is closed under stuttering. This means 
that the entire preamble of stuttered states that might 
change the interpretation of the formula is in fact ig- 
nored, and thus the formula remains closed under stut- 
tering. ■ 
This theorem is the main result that allows us to 
build formulas that contain the "o" operator and are 
still closed under stuttering. The theorem was enabled 
by the formula -lA A oA, which expresses a change in 
A. More exactly, it expresses an up edge in A. We 
denote an up edge by t, a down edge by J,, and an up 
or down edge by J. Their formal definitions follow. 

Definition 2 If A is an LTL formula, then 



u 


= 


-^AAo A 


— up or rising edge 


iA 


= 


A A o-iA 


— down or falling edge 


u 


=^ 


^AV lA 


— any edge 



-"^Notc that wc could not have used □ for quantification as 
it distributes over conjunction. The choice of a quantifier is 
dictated by the boolean operator between F and oB. 



The edges are also called events, as they capture the 
same notion as the events proposed by the Software 
Cost Reduction (SCR) researchers [14, 13]. The SCR 
events cannot explicitly include temporal operators, 
whereas our formalism enables reasoning about events 
in arbitrary LTL formulas. For example, a formula 
I DA has a well-defined interpretation in our language. 
We also note here a strong analogy between our (logi- 
cal) edges and signal edges. Computer engineers have 
made good use of edges in electrical signals — most 
circuitry is driven by edges, e.g. the clock. Edges are 



also widely used in other engineering disciplines, e.g. 
electrical engineering and telecommunications. It is 
surprising that we managed to work around them for 
so long in the model checking world! 



4 Properties 

In this section we present a few important proper- 
ties of edges and closure under stuttering. We begin 
by noting that edges are related by the following for- 
mulas: 



<A = 

lA = 
lA = 






(1) 
(2) 
(3) 



These formulas allow us to switch between the dif- 
ferent types of edges easily. The following are some 
general properties of closure under stuttering: 



a is a variable 


=^ 


<a> 


(4) 


<A> 


= 


<-'A» 


(5) 


<A> A •CB> 


=> 


<AAB> 


(6) 


<A> 


=> 


<nA> 


(7) 


<A> 


=> 


<OA> 


(8) 


<CA> A <CS> 


=^ 


-^AUB:^ 


(9) 



Note that property (5) is an equality indicating that 
when a formula is negated, its closure under stutter- 
ing property is preserved. Property (6) indicates that 
if two formulas are closed under stuttering, then so 
is their conjunction. These two formulas allow us to 
conclude that 

<A> A <CB> =^ <yl * B> 

where * is any of A, V, =>, <^, or =. Such proper- 
ties enable reasoning about closure under stuttering 
of a formula by looking at its components. Finally, 
formula (5) together with (1) and (2) allows the inter- 
changeable use of J, and t when analyzing properties 
of the form 



<CA>: 



fiU) 



Thus, in the rest of the paper we talk only about the 
t-edges in the context of closure under stuttering. 

Below we discuss closure under stuttering proper- 
ties that contain edges and the "o" operator. The first 
property is a corollary of Theorem 1 : 

Property 1 

<A> A <B> A <CC> =^ «>(tA A oB A C)> 



It has two simplified versions: 

<A> A <B> ^ <0(tA A B)> 

and 

<A> A <CB> ^ «>(tA A oB)> 

that we often encountered in practice. In both cases 
an existence property is formalized. The formulas say 
that the event '\A must happen and then B holds. 
In these versions, B is evaluated right before or right 
after the event, respectively. 

Property 2 

<A> A <B> A <CC'> ^^ <n(tA ^ oB V C)> 

This property is logically equivalent to Property 1. Its 
two simplified versions are 



and 



<yl> A «;B> => <n(tA => B)» 



<yl> A <B> ^> <n(tA => oB)> 



They express a universality property: whenever the 
event '\A happens, B will hold. As in the case of Prop- 
erty 1, i? is evaluated right before or right after the 
event, respectively. 

Consider the following example: 

Items should only be dropped on the table. 

This property can be formalized as 

0(^lhold =^ pos = above_tbl), 

where hold is a state variable that is true when we 
hold an item, and pos is a state variable indicating 
the position. Note that an item is considered dropped 
if we hold it in one state and do not hold it in the next. 
Formally, we express "dropped" as hold A o^hold or 
as [hold. 

The last property deals with the "until" operator: 

Property 3 

<yl> A •CB> A <C> A <D> A <CB> A <F> 

=> <C(-T^ M oByC)U {]D AoEA F)> 

There are many simplified expressions for this prop- 
erty which are omitted here for brevity. 
For example, a property 

Initially, no items should be dropped on the 
table before the operator pushes and releases 
the GO button. 



can be formalized as 

^[holdlA [button, 

where hold has the same meaning as before, and button 
is a state variable which is true when the button is 
pressed and false otherwise. 



State 



Edge 



Figure 2: Edge-detecting state 



In order to effectively express properties containing 
edges, it is important to realize that an edge is de- 
tected just before it occurs, as illustrated in Figure 2? 
That is, t^ becomes true in the state where A is false. 
For example, consider the following property: 

After the robot deposits an object on the belt, 
it should not hold another object until the 
sensor at the end of the belt is true. 

If we formalize it as 

n[[hold => {-^hold hi sensor)), 

we do not get the correct formula since its consequent 
would be evaluated one state too early: [hold is de- 
tected when hold is true, but requires hold to remain 
false until sensor is true. The formula can be fixed by 
considering the consequent in the "next" state: 

U{[hold => o[-^holdU sensor)) 



5 Edges and Patterns 

A pattern-based approach to the presentation, cod- 
ification and reuse of property specifications for finite- 
state verification was proposed by Dwyer and his col- 
leagues in [9, 8]. They performed a large-scale study 
in which specifications containing over 500 temporal 
properties were collected and analyzed. They noticed 
that over 90% of these could be classified under one of 
the proposed patterns [9]. 

We discuss two directions for integrating our work 
into the pattern system: extending the system to in- 
clude events based on edges, and evaluating the effec- 
tiveness of our theorems in determining closure under 

^Note that we can move the detection of the edge after it 
occurs if we replace the "next" by the "previous" operator. 



stuttering for the newly created, edge-based formulas. 
In the rest of the section we briefiy discuss the prop- 
erty pattern system (following the presentation in [8] ) , 
describe our extensions based on the usage of edges, 
and conclude with discussing closure under stuttering. 

5.1 The Pattern System 

The patterns enable non-experts to read and write 
formal specifications for realistic systems and facilitate 
easy conversion of specifications between formalisms. 
Currently, the properties can be expressed in a variety 
of formalisms such as LTL, computational tree logic 
(CTL) [5], quantified regular expressions (QRE) [23], 
and other state-based and event-based formalisms. 

The patterns are organized in a hierarchy based on 
their semantics, as illustrated in Figure 3. Some of the 
patterns are described below: 

Absence A condition does not occur within a scope; 

Existence A condition must occur within a scope; 

Universality A condition occurs throughout a scope; 

Response A condition must always be followed by 
another within a scope; 

Precedence A condition must always be preceded by 
another within a scope. 

Each pattern is associated with several scopes — 
the regions of interest over which the condition is eval- 
uated. There are five basic kinds of scopes: 

A. Global The entire state sequence; 

B. Before R The state sequence up to condition R; 

C. After Q The state sequence after condition Q; 

D. Between Q and R The part of the state se- 

quence between condition Q and condition R; 

E. After Q Until R Similar to the previous one ex- 

cept that the designated part of the state sequence 
continues even if the second condition does not 



These scopes are depicted in Figure 4. The scopes 
were initially defined in [9] to be closed-left, open- right 
intervals, although it is also possible to define other 
combinations, such as open-left, closed-right intervals. 
For example, an LTL formulation of the property 
"S* precedes P between Q and i?" (Precedence pat- 
tern with "between Q and i?" scope) is: 

n((Q A OR) ^ {^PU{S V R))) 
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Figure 3: A Pattern Hierarchy. 
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Figure 4: Pattern Scopes. 



Even though the pattern system is fornialisni- 
independent [8] , we are only interested in the way the 
patterns are expressed in LTL. 

5.2 Events in LTL Patterns 

It is often natural to express properties using 
changes of states — edges. As the original pattern 
system was state-based, we tried to extend it by in- 
corporating edge-based events. These events can be 
used for specifying the conditions as well as for defin- 
ing the bounding scopes. For example, we may want 
to express the properties "Event 5* precedes event P 
between states Q and i?" , or "State S precedes state P 
between events Q and i?" . These properties are often 
hard to specify correctly, and since all of them contain 
the "o" operator (either directly or indirectly through 
the use of edges), it is not trivial to determine if they 
are closed under stuttering. 

Introducing edges into the patterns generates an 
explosion in the number of formulas. The patterns 
contain up to two conditions, while the bounding in- 



terval has up to two ends; each of these can be either 
state-based or edge-based, giving us up to 16 different 
combinations. Moreover, when a condition and an in- 
terval end are of the same type (either state-based or 
edge-based), we can choose to make the interval open 
or closed, leading to even more possibilities. Note that 
when the condition and the interval end are of differ- 
ent types, there is no ambiguity because edges occur 
between states. 

Due to the large number of possible formulas, we 
extended only some of the patterns: Absence, Exis- 
tence, Universality, Precedence, and Response. 
In the original pattern system, the conditions were 
represented by formulas P and S, while the bounding 
interval was defined by formulas Q and R. We have 
considered the following possibilities: 



0. 
1. 
2. 
3. 



P, S — states, 
P, S — states, 
P, S — up edges, 
P, S — up edges. 



Q, R — states; 
Q, R — up edges; 
Q, R — states; 
Q, R — up edges. 



Combination corresponds to the original formula- 
tion of [8], where all of P, 5, Q and R are state-based. 
The remaining three combinations are our extensions 
of the pattern system. We assume that multiple events 
can happen simultaneously, but only consider closed- 
left, open-right intervals, as in the original system. We 
note, however, that it is perfectly possible to have for- 
mulas for all other combinations of interval bounds. 
Down edges can be substituted for up edges without 
changing the formulas. 

In Figure 5 we show the LTL formulations for the 
Existence pattern. Each of the scopes is associated 
with four formulas corresponding to the four com- 
binations of state-based and edge-based conditions 
and interval bounds we have considered. We have 
modified several of the 0-formulas (i.e. state-based 
conditions and intervals) from their original formu- 
lations of [8] to remove assumptions of interleaving 



and make them consistent with the left-closed, 
right-open intervals. For brevity, this is the only 
pattern that we detail in this paper. We are currently 
working on integrating our work into the pattern 
system of Dwyer and his colleagues. Meanwhile, the 
complete set of formulas we developed is available at 
http: //www. cs .toronto.edu/~chechik/edges.html. 



5.3 Closure Under Stuttering and Pat- 
terns 



Our primary concern associated with the edge- 
based extension of the pattern system is to analyze the 
newly-created formulas for the closure under stutter- 
ing property. Our interest in this problem is twofold: 
first, we know that edge-based formulas can have prac- 
tical relevance only if they are closed under stuttering, 
and second, these formulas provide a good test-bed for 
the closure under stuttering theorems we have devel- 
oped. 

Let us consider an example: a robot must pick up 
a metal blank from a feed belt, weigh it, and deposit 
it in a press. The specification of the robot says: 



The robot must weigh the blank after pickup 
from the feedbelt, but before the deposit in the 
press. 



The robot is equipped with a magnet and a scale at 
the end of its arm. The status of the magnet is re- 
ported through a state variable mgn which is true 
when the magnet is on, while the scale reports a suc- 
cessful weighing when the state variable scl is true. 

Clearly, this fits the "Existence" pattern: a state 
base condition (weighing) must happen between two 
events (pickup and deposit). In Figure 5, we can find 
the desired formula as D.l. Using '\mgn and [mgn to 
model the pickup and the deposit event, respectively, 
and plugging the events into the template yields the 
formula: 



the template appears below: 

<n(tO A 0]R => o{-.]RUP) A -T^)> 
by the laws of logic and LTL 

n(tQAOTi?=^-T-R)> 

by 6 

<:= <n(tQAOTi?^o(^tfiW^))>A 
<n(tOAOTi?^-Tfi)> 

by Property 2, we get: 
<^ <Q> A <Oti?> A <^^]R U P>A 

<n(tQAOTi?=^-Tfi)> 

by Property 1, this simplifies to: 
<^ <0> A <i?> A <-t-R U P:$>A 

<n(tOAOTi?=^-Ti?)> 

by Property 3, we get: 
<= «3> A <i?> A <i?> A <P>A 

<n(tOAOTi?^-Tfi)> 

by the rules of logic we get: 
= <0> A <i?> A <P>A 

<-O(t0AOtPAtP)> 

by 5 and Property 1: 
<^ <(9> A <i?> A <P>A 
<Q> A <P> A <OTP> 

by Property 1 again: 
<^ <(3> A <P> A <P>A 
<(3> A <P> A <P> 

Thus, we have proven that 
<P> A <0> A <CP> => 

<cn(tQ A OTP ^ o(^tfi UP) A -t^)> 

which is exactly the desired property. 

Note that, although the property is fairly compli- 
cated, the proof is not long, is completely syntactic, 
and each step in it is easy. Similar proofs were found 
for all of the new edge-based formulas [24]. Such proofs 
can potentially be performed by a theorem-prover like 
PVS [28] with little guidance from the user. We are 
currently investigating the feasibility of doing so. 



O^^mgn A Olmgn => o{-^[mgnlA scl) A -ilmgn) 

In order to prove that this property is closed under 
stuttering, we need to show that if components of the 
template, Q, R and P are closed under stuttering, then 
so is the template. Q, R and P are just variables, 
trivially closed under stuttering, and the analysis of 



6 Discussion and Related Work 

Before writing this paper, we searched through nu- 
merous research publications and web sites, looking 
for good examples of LTL formulas containing the 
"next" state, but surprisingly found just a few. We 
also looked at over 500 temporal formulas collected by 
Dwyer and his colleagues [7, 9] and found virtually no 



A. 
0. 
1. 
2. 
3. 


P Exists Globally B. P Exists Before R 
OP 0. OR^^{^PUR) 
OP 1. O^R^i^^RUP) 
O^P 2. OR^^{^]PUR) 
0]P 3. 0]R^^{^]PU]R) 




C. P Exists After Q 

0. Og=^0(QAOP) 

1. OtQ^O(tgAoOP) 

2. og^O(QAOtP) 

3. OTQ=^o(TgAOTP) 


0. 
1. 

2. 
3. 


D. P Exists Between Q and i? E. P Exists After Q Until i? 
n(Q A Oi? ^ ^(^P W i?) A -i?) 0. nCQ ^> if Oi? then ^(^P U R) A ^R else OP) 
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n{QAOR^^{^^PUR)A^R) 2. n(Q ^ if OP then ^(^T^ W P) A -P else OfP 
n(tQAOtP=^-(-T^WtP)A-t^) 3. n(tQ^if OtPthen^(^t^WT^)A-T^elseOTP) 



Figure 5: Formulations of the Existence Pattern 



explicit usage of events or the "next" operator. This 
led us to conclude that the community is almost reli- 
giously avoiding the "next" state operator, replacing it 
with a variety of surrogates, most of which are neither 
elegant nor expressive. 

For example, to simulate an up edge, it is customary 
to create an extra variable, d, that signals a change in 
a by being temporarily true when a is changed. This 
can be modeled by a concurrent assignment to a and 
a: 

atoniic{d ^ 1; a ^ 1; } d ^ 0; 

Note that a is weaker than j a since in systems contain- 
ing more than one process, d is true for a longer time 
than "f o. Since '\a ^ a, replacing j a by d in LTL prop- 
erties can lead to hard-to- interpret verification results. 
For example, a property 

□ (d^Op) 

is a conservative approximation of 

n(ta^ oOp) 

That is, if the former property holds, so does the later, 
but the converse is not true. In many such cases the 
approximation is too strong, forcing the user to modify 
a possibly correct model just to be able to verify the 
property. Such approximations can be so strong that 
they are always false in most models. For example, 
performing the substitution in the formula: 

n(ta^o(^taWT6)) 

will most likely result in a formula that is always false 
because d can be true for several consecutive states. 
A property 



is an optimistic approximation of 

0(ta A T&) 

That is, if the former property does not hold, neither 
does the later, but the converse is not true. This means 
that the approximation cannot be used for checking 
the validity of the model. Combining conservative and 
optimistic approximations can void the resulting for- 
mula of any meaning. 

The users of the model-checker SPIN [16] proba- 
bly constitute the largest LTL user-group''. However, 
judging from the four years of proceedings of the SPIN 
workshop, available at [20], they seldom if ever use 
properties involving events because of the common 
misconception that no formulas containing "next" are 
closed under stuttering, expressed, e.g., by Kamel and 
Leue in [17]. This is, in our opinion, a serious problem 
because we believe that edges are required to express 
most nontrivial properties. For example, during our 
work [26] on the Production Cell [19], edges were re- 
quired in 10 out of 14 properties that we formalized, 
and in many of these, simulating edges by introducing 
extra variables was not possible. 

A restricted use of "next" , similar to ours, is also 
advocated by Lamport in his Temporal Language 
of Actions (TLA) [18], where "next" is replaced by 
"primed variables", e.g., a' indicates the value of a 
in the next state. However, this is not sufficient to 
guarantee closure under stuttering and an additional 
restriction is placed on the TLA formulas. This re- 
striction is similar in form to the one imposed by The- 
orem 1. 



0(d A b) 



^SPIN has over 4000 installations world-wide. 



7 Summary and Conclusion 

The "next" operator in linear-time temporal logics 
is required for reasoning about events. However, it 
is seldom if ever used in practice because of a false 
belief that it does not allow construction of formulas 
that are closed under stuttering. Instead, people in- 
troduce extra variables to simulate events. These vari- 
ables clutter the model and make it harder to analyze. 
Moreover, results of the verification with respect to 
these properties often cannot be interpreted correctly 
without complete understanding of the modeling lan- 
guage and logic, leading to errors among novice and 
even expert users. 

In this paper, we have introduced the notion of 
edges in the context of LTL, a concept that allows us 
to easily express temporal properties involving events. 
We have also provided a number of theorems that en- 
able syntax-based analysis of a large class of formu- 
las for closure under stuttering. These theorems can 
be easily added to a theorem prover for mechanized 
checking. In addition, we extended the patterns iden- 
tified in [8] with event-based formulations, and proved 
that the resulting formulas are closed under stuttering 
using the theorems presented in this paper. Unfortu- 
nately, unlike the "next" -free LTL, our language of 
edges is not closed, i.e., it is possible to use this lan- 
guage to state a property which is not closed under 
stuttering. However, we feel that it can express and 
enable analysis of the majority of formulas that are 
encountered in practice. For example, we were eas- 
ily able to check the formalization of properties of the 
Production Cell System. 

We hope that the work presented in this paper will 
contribute to increasing the usability of formal meth- 
ods, at least in the linear-temporal logic domain. 
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